2. Running Multi-Server Queries
One of the appealing new
features in SQL Server 2008 is the ability to execute a single query
against multiple servers. This can save many hours of mundane work
during your career as a DBA. How many times have you written a script
that you needed to run on each of your servers? You would not only
waste time running the script on each server, but if you needed a
centralized result set, you would have to manually combine the results
as well. Multi-server queries are not just for selecting data
either—think about it from a deployment perspective. For example, you
can push a new stored procedure to all the servers in a given group.
For that matter, you could even create a new database on every server
in the group just by running a single statement. Any script you can
write that is compatible with the different versions and editions of
all the instances in the group is fair game for execution as a
multi-server query.
To run a multi-server query,
right-click on a server group and select New Query from the context
menu. We will be using the Production group created in the previous
section. Clicking New Query from the context menu will open a new query
editor window. Your status bar should be a light shade of pink instead
of the yellow color that is normally displayed. The status bar will
also show the number of servers that the query will execute against by
displaying the number of connections made and the number of servers in
the group. For example, if you have four servers in a group, you should
see Connected (4/4) in the status bar if you are able to make a
connection to all four servers. Another interesting thing that happens
is that the database drop-down menu is limited to only the databases
that are shared by all the servers in the group.
Now we are ready to execute
a query. We will execute a simple query to return the name of all the
user databases in the server group. For example:
Select name From sysaltfiles Where dbid > 4
Since we have a SQL 2000 instance in the group, we will use the sysaltfiles table instead of the sys.sysaltfiles table that was not available until SQL 2005. Figure 5 shows a result set after executing the query against a group of servers.
If you look at the status bar in Figure 5,
you can see a couple of interesting data elements. The status bar shows
the name of the group the query is executing against, the user who is
executing the query, and the database the query will be executed
against. You also may have noticed that the query includes the name of
each server as a part of the result set, even though we did not
specifically add it to the query.
You can also run
multi-server queries using local server groups by registering the
servers and running a query against a specific group. The benefit of
using a local server group to run a multi-server query is that you can
include the central management server in the local server group.
Remember that a central management server cannot be a part of the group
it is managing, so there is no way to include the server that is
managing the groups in the result set. Another benefit to using local
server groups to run multi-server queries is that you can register the
servers using Windows authentication or SQL Server authentication. The
downside to using local server groups is that the groups that are
created are local to each DBA. A central management server allows DBAs
to share a common registered server group.